Sprint Retrospective

Resumen ejecutivo

La intención del documento es reflejar por escrito el trabajo realizado por el equipo y sus procesos, para analizar y observar qué ha ido bien para elogiarlo, qué ha ido mal para tener consciencia de ello y qué hay que mejorar para futuros proyectos.

Metodología del equipo de desarrollo

En este primer apartado, se procede a analizar con detalle el cumplimiento del equipo ante las normativas declaradas de cara a afrontar el proyecto. Tras ello, se destacan las siguientes:

Gestión de Issues

Tras la replanificación del Sprint 3 se han añadido nuevas issues referentes al feedback recibidido, además alguna pequeña tarea que no se había tenido en consideración anteriormente. Tras haber afrontado problemas en cuanto a la planificación y el retraso de algunas de estas acarreadas de anteriores sprint, se reasignaron las tareas teniendo en cuenta los tiempos de los distintos miembros del equipo de trabajo. En este punto, podemos destacar:

• Reducción del alcance: Se ha llevado a cabo una reducido el alcance del proyecto, debido a esto se cerraron varias tareas.
• Mejora de la planificación: Se procedido a crear una issue por semana, en la cuál se detallan aquellas tareas surgidas a través del feedback recibido en clase, para poder llevar un mejor seguimiento de estas. Esto nos ha ayudado a tener una organización más clara y limpia por parte de los coordinadores de cara a la organización del equipo.

Gestión de ramas

Durante el Sprint #3, se ha seguido manteniendo la misma política de ramas (GitFlow), ya que esta funciona especialmente bien en el equipo de trabajo. A continuación, se explayan con rigurosidad los detalles sobre el tema:

• Nomenclatura de las ramas: salvo pequeños casos, la nomenclatura de las ramas en este Sprint se ha respetado mucho más que en el anterior, ya que al mejorar la comunicación con el equipo y realizar una guía de acceso rápido del reglamento y políticas a seguir, la mayoría estuvo al tanto de la normativa a seguir.
• Posición de ramas y cierre: de la misma forma, se ha respetado la división de las ramas desde develop, de la misma forma que antes de subir los cambios de una épica a develop, todas las subtareas deberán integradas en su rama épica correspondiente. De igual manera que en el anterior Sprint, las ramas en las que se haya finalizado el trabajo y se encuentren ya integradas en develop, han sido borradas para la limpieza del repositorio.

Commits y Pull Request

Tras comprobar en detalle algunas de las ramas del equipo de trabajo en los repositorios del proyecto, se puede observar que generalmente se ha cumplido con los establecido. Analizamos en detalle:

• Commits: generalmente, se han encontrado como se despachaba en la normativa, es decir, commits atómicos y sintetizados sobre que se incluye en este. Aunque hay alguna que otra excepción de commits que no siguen ni la estructura adecuada o que no son atómicos, pero son casos aislados.
• Pull Requests: debido a la mejora de la comunicación dentro de los canales ofrecidos en GitHub, el equipo de trabajo ha realizado una gran labor en comunicar mediante Pull Requests los cambios a integrar en otras ramas, arraigado a buenas reseñas por parte de otro miembros del equipo. Además, esta vez dentro del tablero Kanban no han quedado reflejadas las Pull Requests que se realizaban, por lo que el Product Backlog del GitHub Projects se ha respetado. En su lugar, se dedica una columna especial en el Project destinada a las Pull Requests aceptadas.

Commitment Agreement

En términos generales, se puede decir que el cumplimiento ha sido bueno por la mayoría de los miembros del equipo de trabajo, elogiando sobre todo el buen trabajo realizado en la colaboración y la comunicación en este Sprint. Sin duda, la decisión de priorizar GitHub como canal de comunicaciones ha ayudado a mejorar la colaboración y la comunicación del equipo, de tal forma que todo el mundo es consciente del cambio y las solicitudes que se realizar mediante un único medio y por varios como lo realizado en el anterior Sprint.

Sin embargo, también hay que saber reconocer los errores, por lo que a continuación se detallan los cometidos relacionados con el Commitment Agreement:

• Dedicación de tiempo: Debido a la complejidad de nuestro proyecto, no hemos podido ajustarnos a los tiempos marcados por la asginatura, necesitando por ello realizar algunas horas extras.
• Compromiso de esfuerzo: A causa del cansancio acumulado hasta la fecha sumado a la semana festiva, el nivel de esfuerzo general del equipo se ha visto comprometido.

Reflexión del Sprint

El apartado se dedica a hacer una reflexión general sobre cómo ha funcionado el Sprint en términos de interacción con el equipo y los procesos establecidos.

Este último sprint del proyecto ha progresado según lo planificado. Se han cerrado tareas dentro de los plazos establecidos, cumpliendo con nuestras métricas de calidad y lo que es más importante, cumpliendo con nuestro alcance propuesto.

En general, el equipo de trabajo se ha visto afectado por el cansancio y la exigencia de esta "recta final", aunque, no por ello se ha perdido la ilusión inicial. El equipo está contento de haber sacado adelante este proyecto.

Por último, destacar que es ahora, al final de este sprint en el que se ven los frutos de toda la planificación y estrategias de gestión que se elaboraron al comienzo de la empresa.

• Logros y éxitos:

  • Registro del tiempo: hay que elogiar el buen trabajo realizado para controlar el tiempo. Tras el feedback recibido, se actuó rápido para crear nuevas etiquetas, instalar extensiones, etc. Además, la revisión constante de los coordinadores ha permitido detectar errores de estándares en el Clockify con mucha rapidez.
  • Documentación: como en el anterior Sprint, el equipo de trabajo se puede sentir orgulloso de tener una documentación de calidad, al redactar documentos con rigurosidad, hacer revisiones constantes y aplicar procesos de calidad para el aseguramiento de una buena redacción.
  • Planificación: este también es un gran punto a destacar, ya que la reestimación del Product Backlog, ha permitido mejorar la forma de trabajar de los miembros del equipo, con tareas más sencillas y más detalles, intentando a su vez lograr un equilibrio de horas entre todos los miembros, además de gestionar de forma rápida todas las semanas el surgimiento de nuevas tareas tras recibir feedback del profesorado.
  • Mitigación de riesgos: de nuevo, se ha llevado una buena mitigación de riesgos por parte del equipo tras tener un buen plan desarrollado para el mismo.
  • Gestión de la comunicación: este es el punto más destacable de este Sprint. El uso de un único canal común a todos los miembros del equipo, ha permitido mejorar la constancia del cambio y la calidad de la comunicación, con mejor recepción de la información en las tareas, discusiones, etc.
  • Código bien implementado si bien la llegada de código funcional ha sido algo tardía, lo que se tiene de este es bastante sólido, considerando múltiples casos y limitaciones. Asimismo, se han ejecutado sus respectivas pruebas para garantizar su funcionamiento correcto, aunque es cierto que estas se han visto disminuidas a lo largo del proyecto.

• Desafíos y dificultades:

  • Entorno de desarrollo: de nuevo, el entorno de desarrollo ha supuesto un grave problema para un flujo normal de trabajo. A pesar de que se ha tratado de gestionar de la mejor forma, el proyecto era demasiado ambicioso y no se había tenido en cuenta su alta complejidad desde un inicio, causando esto dificultades constantes a lo largo de la etapa de desarrollo.
  • Complejidad de las tecnologías a utilizar nuevamente las herramientas que se usan resultan complejas para la mayoría de integrantes del equipo, dificultando la finalización en tiempo de las tareas de desarrollo, necesitan en algunas de ellas más personas de las inicialmente planteadas, cosumiendo esto horas del proyecto.
  • Cierre de tareas debido a que los miembros del equipo no siempre estaban disponibles para aceptar las Pull Requests han habido tareas que han permanecido en revisión durante mucho tiempo sin poder cerrarse.
  • Dependencia de tareas en este sprint hemos mitigado en gran medida los problemas que habíamos tenido anteriormente con las depencencias entre tareas, para que todos los miembros pudieran trabajar de forma paralela.
  • Surgimiento de tareas no contempladas en este sprint se han surgido nuevas tareas, que no se habían tenido en cuenta en el Product Backlog como la implementación de API de anuncios, que se había planteando en los planes de precio, pero no estaba reflejada en el Product Backlog.

Plan de acción

De esta manera, tras analizar las circunstancias que se han dado durante el Sprint, se puede obtener el siguiente plan de acción, el cual está destinado a anotar aquellas mejoras y consejos para comenzar a tener en cuenta por los integrantes para el próximo entregable, o “start doing”, situaciones que el equipo debería continuar haciendo, o “continue doing”, ya que funcionan y se hacen de manera correcta y acciones que se deben de dejar de hacer porque están perjudicando el desempeño grupal, o “stop doing”.

Con este plan de acción se pretende que todos los miembros del equipo tengan constancia de qué acciones son viables y lo apliquen para siguientes entregables o proyectos. A continuación, se muestra la lista:

START	STOP	CONTINUE
Planificar mejor a los usuarios pilotos	Dejar las pull request abiertas por mucho tiempo	Hacer documentos con alta calidad
Agilizar la gestión de errores software	Desinterés por la asignatura de algunos miembros	Mantener una buena comunicación
Realizar una estimación más exahustiva de las tareas	Estar ausente en un largo periodo de tiempo por los medios de comunicación	Registro de horas en Clockify
Fomentar la participación activa de todos los miembros del equipo	Superar las 10 horas semanales	Monitorizar correctamente y semanalmente los riesgos
	Incumplir el Customer Agreement	Hacer la documentación en Docusaurus directamente
	Retrasar las tareas hasta el límite	Asignar tareas equitativamente
		Seguir el Commitment Agreement